Many hosts today are multi-homed. Hence, they have multiple paths for connectivity via one or more access technologies. Regular Transmission Control Protocol (TCP)/Internet Protocol (IP) communications restrict these multi-homed hosts to use only one of the available interfaces/paths per session, where a path is defined as an (source, destination) IP address pair. The Internet Engineering Task Force (IETF) is currently looking into a mechanism which uses multiple paths between the communicating peers simultaneously during a communication session. Request for Comments (RFC) 6824 proposes a set of extensions to traditional TCP for multipath operations when multiple addresses are available. This is referred to as ‘Multipath TCP’ (MPTCP).
Advantages of using multiple paths concurrently are: i) improved network resource utilization (e.g., increased bandwidth due to resource pooling); ii) improved user experience through higher throughput; iii) allows failover from one interface to another (e.g., mobile client); and iv) allows a single data connection to use several interfaces simultaneously. A usage scenario for MPTCP is illustrated in FIG. 1.
As shown in FIG. 1, two communicating hosts, host A and host B, are multi-homed and multi-addressed. Each host provides two separate connections to the Internet offering four different paths between them (A1-B1, A1-B2, A2-B1 and A2-B2).
A traditional TCP connection between the hosts A and B will make use of only one of the available paths whereas an MPTCP connection makes use of all the four available paths between hosts A and B. An “MPTCP connection” is similar to a regular TCP connection and is defined in RFC 6824 as: “a set of one or more subflows, over which an application can communicate between two hosts”. A subflow is defined in RFC 6824 as: “A flow of TCP segments operating over an individual path, which forms part of a larger MPTCP connection”. A subflow is started and terminated similar to a regular TCP connection. A TCP subflow may be called an MPTCP subflow when forming part of an MPTCP connection.
MPTCP is an end-to-end protocol which requires both hosts to support MPTCP (i.e., it requires both hosts to have an MPTCP protocol stack that includes an MPTCP protocol layer on top of one or more TCP/IP stacks) to benefit from MPTCP. Since, MPTCP is still in its early stage of deployment, probabilities that every host on the Internet supports MPTCP are very low. To overcome this problem and benefit from MPTCP even though both communicating hosts do not support MPTCP, an MPTCP proxy (a proxy server) may be used to convert MPTCP connections to TCP and vice versa.
One use case is illustrated in FIG. 2, in which an MPTCP-capable user equipment (UE, Host A) is controlled by the operator and sets up several MPTCP subflows to the MPTCP proxy placed in the telecommunications operator's network. This proxy in turn sets up a single TCP flow to a server on the Internet (Host B) which is not MPTCP capable. In the described scenario, the UE which supports MPTCP can still get the benefits of MPTCP although the server at the other end is not aware of MPTCP. It may be noted that a proxy may be used even if both end-points (i.e. also the server in this case) are MPTCP capable and MPTCP is run on both sides of the proxy.
So the main principle of Multi-Path TCP (MPTCP) is to aggregate a set of TCP connections, for example over different wireless interfaces such as in accordance with a third generation partnership project (3GPP) communication standard and a wireless local area network (WLAN, e.g. Wi-Fi) communication standard (or even different simultaneous 3GPP accesses). As the multiplexing of different connections is on TCP level, it allows separate congestion control for each subflow.
FIG. 3 shows the differences between standard TCP and MPTCP protocol stacks. The application interface i.e. the socket application programming interface (API) is unchanged and the main changes are between this API and the IP-layer.
MPTCP provides the possibility to fully and maximally utilize the different TCP subflows. For example, in the case of one TCP subflow on a 3GPP access and another one on Wi-Fi access, the total throughput could be the sum of these subflows. FIG. 4 shows a user plane protocol architecture example for the case when MPTCP would be utilizing a 3GPP long term evolution (LTE) communication standard and WLAN/Wi-Fi simultaneously.
FIG. 5 shows an example case of MPTCP in action when the UE is simultaneously connected to both LTE and Wi-Fi/WLAN. The application in the UE has opened up one TCP socket and is sending a stream of bytes on the internal API. The MPTCP layer (also called MPTCP scheduler) has established two different TCP subflows, subflow 1 via WLAN/Wi-Fi (the curved dashed line) and subflow 2 via LTE (the curved solid line). Both these subflows are in this example towards an MPTCP Proxy that further communicates with another server using plain TCP (shown as a TCP connection to the far right in the figure). The MPTCP scheduler is the function that decides how the different packets are mapped to the two subflows. In this example, the MPTCP scheduler is applying “round-robin” scheduling i.e. a first TCP segment is sent on subflow 2, a second on subflow 1, a third again on subflow 2 etc. Another example is that MPTCP scheduler uses the subflow with the shortest round-trip time (RTT). Such an approach is typically used in today's MPTCP kernel prototype implementations.
Either of the hosts in an MPTCP communication may request that a subflow is only used as backup, and thus only used if other subflows fail. This is typical in the case when MPTCP is only used for “seamless session continuity at mobility” (e.g. the case of failover from one interface to another) and has been described as being done by sending a SYN flag in the MP_JOIN option when a new TCP subflow is added to a MPTCP connection, including four bits, three of which are currently reserved and must be set to zero by the sender. The final bit, labelled “B”, indicates whether the sender wishes this subflow to be used as a backup path (B=1) in the event of failure of other subflows, or whether it wants it to be used as part of the connection immediately. By setting B=1, the sender is requesting the other host to only send data on this subflow if there are no available subflows where B=o. The “B” bit can also be updated dynamically for an established TCP subflow of an MPTCP connection using the MP_PRIO option.
The current MPTCP implementations available in devices (e.g., end user devices (e.g. UE), servers, and other devices) only utilize the “seamless session continuity at mobility” benefit of MPTCP, i.e. throughput aggregation is not used. The main reason for this is the fact that WLAN access is currently seen as a cheaper access compared to 3GPP accesses and therefore a preference for using WLAN/Wi-Fi (a.k.a., the “use Wi-Fi if available” preference) is currently also used in the context of MPTCP.
However, throughput aggregation will likely be used in the future, e.g. with concurrent MPTCP subflows over both WLAN and 3GPP accesses. Neither the WLAN nor the cellular 3GPP networks will then be aware that the traffic sent over it is sent over an MPTCP connection with a plurality of subflows. The respective networks are thus not able to treat the MPTCP subflow bearers any differently than regular TCP bearers. This applies also for the “seamless session continuity at mobility” case.